home *** CD-ROM | disk | FTP | other *** search
/ TOS Silver 2000 / TOS Silver 2000.iso / Anwendun / Pov / POV302 / DOCS / ATARI / POVTIPS.TXT < prev   
Encoding:
Text File  |  1997-07-11  |  5.6 KB  |  119 lines
  1.  
  2. Some quick tips for stress-free raytracing on smaller systems!
  3.  
  4. * Try to use a small preview size during development, as it
  5.   improves develop/test turnaround time.
  6.  
  7. * Don't set the rendering quality any higher than required
  8.   for any particular job. There is no point in producing lots
  9.   of colours, textures, shadows or reflections when you are
  10.   still working on the shape of the objects in the scene!
  11.  
  12. * Don't use anti-aliasing unless you are ready to produce the
  13.   final draft of your image. It slows the rendering process
  14.   down a great deal, and that is not helpful when you are in
  15.   the middle of developing of your scene.
  16.  
  17. * Avoid really intensive functions until quite late in the
  18.   development of your scene. That means atmospherics, focal
  19.   blur, fractal shapes and other processor-killing effects.
  20.  
  21. * Set up a few different camera angles using equates or
  22.   variables at the top of your scene. By commenting in or
  23.   out these camera angles, you will be able to examine the
  24.   parts of the scene you are working on from various angles
  25.   without a lot of mucking about in the camera definition.
  26.  
  27. * Leave the verbose and console stream options enabled while
  28.   developing your scene, or you won't see the errors that
  29.   pop up all too often during development. That can be very
  30.   confusing!
  31.  
  32. * If your scene is rendering slowly, then reduce the 'abort
  33.   test count' value in POVRAY.INI. This will let you break 
  34.   out of a render more quicky and can save time.
  35.  
  36. * If your scene is rendering rather quickly, then increase 
  37.   the 'abort test count' value. It saves on unwanted keyboard
  38.   checks that are needed less frequently during fast renders.
  39.  
  40. * If you are about to attempt an overnight render, then you
  41.   should turn off any user-interactive checks and responses
  42.   to save on rendering time. That means turn off the display
  43.   preview mode, the verbose mode, the console stream and even
  44.   the abort-test function. On the Falcon, this will cause the
  45.   screenblanker to kick in, so be warned that the screen will
  46.   remain black until the render is finished. For that reason
  47.   it is important to disable the pause-when-done function or
  48.   you may never know it's actually finished!
  49.  
  50. * If you are going to attempt an animation, then make sure
  51.   you disable the pause-when-done function or POV will wait
  52.   for a keypress between each frame. That could be nasty!
  53.  
  54. * When using the preview mode, it helps to leave the 'draw
  55.   vistas' function enabled, as it gives you an idea of where
  56.   the nasty (slow) bits of the image are - and therefore a
  57.   better idea of how long it's going to take before it's all
  58.   finished.
  59.  
  60. * Don't output the image to a file unless you can't use the
  61.   preview mode (ST/E users) or unless you are ready to render
  62.   a final or otherwise 'useful' version. File output can slow
  63.   down the rendering process a little, and that's not very
  64.   helpful during the develop/test cycle.
  65.  
  66. * Targa files may be big, but they contain all of the colours
  67.   produced at render time and so maintain the image quality.
  68.   Stick with Targa for as long as you can, unless you need to
  69.   convert another format for very well defined reasons.
  70.  
  71. * It's wise to enable the continue-trace option when rendering
  72.   large files to disk, in case you suffer a crash or other bad
  73.   accident.
  74.  
  75. * If a render is badly interrupted, it is possible that it can
  76.   never be continued without being repaired first. This is not
  77.   easy for beginners, but it can be done with the right tools.
  78.   In other words, don't throw your image away just because you
  79.   managed to render 350 lines out of 400 and it won't continue
  80.   properly. Keep the file and contact a POV expert and you
  81.   might be able to salvage the image!
  82.  
  83. * The anti-alias threshold is a bit tricky to get right, and
  84.   it will vary in sensitivity between the two pixel sampling
  85.   methods available (methods 1 and 2). For this reason, it is
  86.   best to start with a large (low sensitivity) value and work
  87.   downwards. The smaller the value, the more anti-aliased the
  88.   image will be, and the slower it will render! A good start
  89.   point is about 0.1, but you may find that is far too large
  90.   and leads to rough edges. I find 0.0625 is not bad for most
  91.   renders.
  92.  
  93. * Choosing a sampling method is very tricky, and it's more
  94.   down to experience than anything else. As a rough guide, 
  95.   method #1 uses neighbour-checks to decide if a pixel is
  96.   unlike it's neighbours enough to merit anti-aliasing the
  97.   pixel with extra rays (usually 3x3 = 9 rays). That means
  98.   some pixels will be missed, but it's good enough for most
  99.   types of scene. Method #2 is much cleverer. For every group
  100.   of 2x2 pixels rendered, it decides if those pixels are far
  101.   enough apart (intensity-wise) and if they are, it subdivides
  102.   the grid into four smaller sets of 2x2 by casting some extra
  103.   intermediate rays - and then it tries again. The 'antialias
  104.   depth' value has a different meaning for each method. When
  105.   using method #1, it decides the 'width' of the ray cluster
  106.   fired at the offending pixel (3 = 3x3 = 9 rays). When using
  107.   method #2, it decides the maximum depth the subdivision can
  108.   reach for any group of 'start' pixels. Subdivision is much
  109.   slower than simple neighbour-checks, but it is able to cast
  110.   fewer rays because it's smarter. It can be anything from a
  111.   little faster to a lot slower than method #1, but it does
  112.   look a lot better most of the time.
  113.  
  114. * If your scene uses lots and lots of objects inside unions,
  115.   it is worth turning on 'split unions'. This can speed up
  116.   rendering quite a lot as it allows the the sub-objects to
  117.   be rendered using the vista buffer.
  118.  
  119.